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ABSTRACT 

We  propose  an  approach  to  the  use  of  rule-based  programming  tech- 
niques to  the  construction  of  intelligent  control  systems.  Specifically,  we 
address  the  problem  of  generating  real-time  responses  from  a  rule-based 
system.  The  technique  is  based  on  the  observation  that  many  control  sys- 
tems are  in  fact  working  in  finite  domains,  and  thus  can  be  speeded  up  by 
replacing  general  rules  with  selected  instantiations.  Two  techniques  for 
reducing  the  number  of  necessary  instantiations  are  presented:  one  con- 
sists of  decomposing  the  system  into  separate  components  for  recognizing 
one  of  a  finite  number  of  control  modes,  and  for  executing  the  control 
responses  for  each  of  these  modes;  the  second  consists  of  a  simple  learn- 
ing method  for  selecting  instantiations.  This  approach  trades  space  for 
time,  and  is  estimated  to  be  able  to  give  speed  improvements  of  up  to 
1000  on  a  serial  processor,  and  significantly  more  using  parallelism. 

1.  Expert  Control  Systems 

We  are  interested  here  in  the  application  of  rule-based  programming  techniques  to 
the  construction  of  intelligent  control  systems.  We  will  refer  to  these  as  expert  control 
systems. 

An  expert  control  system  is  one  in  which  is  embedded  substantial  knowledge  about 
the  problem  to  be  solved.  Problems  which  require  such  an  approach  include  driving  a 
car,  flying  a  plane,  operating  a  chemical  plant,  supervising  a  hospital  patient,  and  for 
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many  applications  controlling  a  robot.  Here  we  will  ignore  the  problems  of  perception 
which  are  of  course  crucial  in  most  of  these  applications,  and  concentrate  on  the  control 
logic.  An  important  requirement  of  the  control  logic  is  that  it  must  operate  in  real-time; 
inputs  must  usually  be  sampled  at  regular  intervals,  and  outputs  must  be  continuously 
updated. 

1.1.  Real-time  Requirements 

The  real-time  requirement  imposes  severe  constraints  on  the  kind  of  organization 
which  can  be  used  for  control  systems.  We  will  assume  for  the  sake  of  discussion  that  the 
basic  form  of  the  control  system  is  iterative,  a  repeated  cycle  consisting  of  computing 
output  values  as  a  function  of  the  input  values.  In  practice  the  time  constraints  of  this 
cycle  will  vary,  but  clearly  some  situations  will  be  more  critical  than  others.  These  cause 
severe  problems  for  traditional  forms  of  rule-based  systems,  which  are  relatively  slow, 
(estimates  suggest  10-100  productions  per  second  for  a  1  MIP  processor).  We  propose 
here  a  mechanism  for  improving  this  performance  by  a  factor  of  about  1000. 

Our  approach  actually  grew  out  of  observations  of  a  number  of  expert  systems 
[Stolfo79,  Benjamin83,  Henkind84]  we  have  worked  with,  but  it  can  most  simply  be 
illustrated  by  analogy  with  the  behaviour  of  human  experts  acting  as  control  systems. 

2.  Human  Control  Systems 

Consider  the  following  rather  simple  example:  racing  a  sailboat.  This  is  a  task 
which  is  generally  recognized  to  require  both  split-second  responses  and  also  highly 
sophisticated  tactical  and  strategic  decision-making. 

A  human  expert  sailor  has  general  knowledge  in  a  large  number  of  areas.  He  (she) 
knows  the  principles  of  how  to  convert  the  wind  into  forward  motion  of  the  boat,  and  the 
standard  methods  for  setting  the  sails  for  different  kinds  of  wind  conditions.  He  has  an 
intimate  knowledge  of  the  racing  rules,  and  is  famiUar  with  a  number  of  tactical  manoev- 
ers  for  dealing  with  situations  in  which  boats  are  in  close  proximity.  He  also  has 
knowlege  of  general  strategies:  which  side  of  the  course  to  go  for,  when  to  tack  or  jibe, 
and  when  to  be  cautious  or  aggressive.  He  has  knowlege  about  weather,  including  the 
effect  of  land  and  sea  conditions  on  the  wind.  Lasdy,  he  has  knowledge  about  particular 
boats:  optimum  sail  settings  for  various  conditions,  how  long  the  boat  takes  to  turn  or  get 
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up  speed,  and  how  close  to  the  danger  point  it  can  be  driven. 

However,  when  an  expert  sailor  gets  on  an  unfamiliar  boat,  he  has  to  apply  his  gen- 
eral knowledge  to  a  new  situation.  He  knows  that  he  will  have  to  make  immediate  deci- 
sions in  complex  situations,  and  he  will  not  have  time  to  resort  to  his  general  knowledge. 
He  spends  the  first  hour  looking  round  the  boat,  familiarizing  himself  with  its  particular 
properties.  During  the  first  few  days  of  sailing,  he  is  constantly  learning  about  its  han- 
dling characteristics,  and  incorporating  these  into  his  'control  system'.  It  is  generally 
thought  to  take  about  a  year  of  sailing  before  this  process  is  complete,  though  there  are 
instances  of  sailors  who  win  championships  within  six  weeks  of  setting  foot  in  a 
unknown  boat. 

We  now  observe  that  in  spite  of  their  apparent  complexity,  human  control  systems 
can  usually  be  described  as  being  in  one  of  a  finite  number  of  modes.  In  our  sailboat 
example,  the  helmsman  is  in  one  of  a  relatively  small  number  of  modes  (beating,  reach- 
ing, running,  tacking,  jibing,  rounding  a  buoy,  say).  The  control  function  exercised  is 
then  a  function  of  the  mode  and  the  (usually  continuous)  input  variables.  We  argue  that  it 
is  the  finiteness  of  the  control  system  which  permits  efficient  performance. 

We  suggest  that  during  the  learning  of  a  new  skill,  the  human  builds  his  control  sys- 
tem in  the  following  way.  He  specializes  his  general  knowledge  for  the  specific  situa- 
tion. He  analyses  it  with  the  express  objective  of  choosing  a  finite  number  of  modes.  He 
then  decomposes  the  control  into  a  component  which  identifies  the  mode,  and  a  com- 
ponent which  carries  out  the  control  functions  for  that  mode.  He  then  constructs  efficient 
algorithms  to  recognise  the  situations  which  correspond  to  each  mode,  and  to  compute 
the  control  responses  for  each  mode. 

We  note  here  that  in  many  human  control  systems,  the  critical  times  for  the  recog- 
nize and  the  compute  cycles  may  be  quite  different.  In  our  sail-boat  example,  the  execute 
cycle  must  be  responsive  to  changes  in  fractions  of  a  second,  while  changing  modes  may 
take  seconds. 

Below  we  will  discuss  what  might  be  the  analog  of  these  processes  for  an  expert 
control  system.  Before  doing  so,  we  discuss  some  of  the  theoretical  issues  which  are 
involved. 
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3.  Finite  Domain  Experts 

We  use  this  phrase  to  refer  to  expert  systems  which  operate  in  a  finite  (though  possi- 
bly very  large)  domain.  From  the  theoretical  point  of  view,  the  finiteness  of  the  domain 
is  of  great  significance.  In  first-order  logic,  the  domain  of  a  set  of  clauses  is  usually 
defined  to  be  the  set  of  values  which  can  be  taken  on  by  terms  which  are  elements  of  the 
Herbrand  universe  of  the  set  of  clauses.  If  this  Herbrand  universe  is  finite,  there  is  an 
algorithm  which  will  determine  if  the  statement  is  valid.  Furthermore,  the  system  can  be 
reduced  to  prepositional  logic,  for  which  there  are  much  more  efficient  representations 
and  algorithms.  In  the  particular  case  when  the  clauses  are  Horn  clauses,  as  is  the  case 
for  the  Prolog  model,  there  is  a  highly  efficient  algorithm  whose  time  complexity  is 
linear  in  the  size  of  the  propositional  form  of  the  statement. 

For  systems  such  as  Prolog  and  OPSx*,  this  means  essentially  that  pattern-matching 
can  be  eliminated.  In  Prolog  each  literal  can  be  linked  directly  to  those  clauses  which 
can  be  used  to  solve  it  (a  finite  number),  while  in  OPSx  each  literal  added  to  working 
memory  can  be  linked  to  all  rules  which  could  fire. 

Our  case  does  not  satisfy  the  finite  Herbrand  universe  requirement,  a  very  strong 
restriction,  since  the  input  variables  are  in  general  continuous.  Furthermore,  we  cannot 
necessarily  infer  that  only  a  finite  part  of  the  Herbrand  universe  participates  in  the  con- 
struction of  the  answer,  even  if  the  number  of  answers  is  finite  (consider:  tack  if  the 
wind-strength  in  knots  is  a  prime  number). 

On  the  other  hand,  it  is  clear  that  if  in  addition  the  inputs  are  discrete,  the  number  of 
possible  inputs  is  finite,  the  number  of  ways  of  inferring  the  answer  is  finite,  and  the  part 
of  the  Herbrand  universe  which  can  participate  in  constructing  an  answer  is  also  finite. 
This  suggests  that  we  approximate  the  system  by  discretizing  the  inputs.  Unfortunately  if 
done  in  a  straight-forward  way  this  approach  either  leads  to  a  combinatorial  explosion  in 
the  number  of  rules,  or  to  an  inaccurate  model  of  the  system. 

However,  we  believe  that  in  practice  most  control  systems  (and  in  fact  many  expert 
systems)  do  operate  in  a  finite  domain.  We  consider  a  program  P  which  consists  of  a  set 
S  of  clauses,  a  clause 


*  We  use  OPSx  to  refer  to  the  generic  production  system  as  exemplified  by  systems  such  as  0PS5 
[Forgy81]. 


input(i), 

a  set  E  of  evaluatable  functions  and  predicates,  and  a  query  of  the  form: 

?-  answer(Y). 

We  define  the  effective  domain  of  P  to  be  the  ininimum  set  of  functions  of  i  which  need 
to  be  constructed  to  satisfy  the  query,  regardless  of  the  value  of  i.  We  say  that  P  is  Si  finite 
domain  program  if  the  effective  domain  of  P  is  finite.  This  clearly  requires  that  the 
number  of  answers  is  finite. 

To  illustrate  this,  consider  the  case  of  Prolog  programs.  These  certainly  have  finite 
domains  if  they  are  free  of  infinite  loops,  which  of  course  is  undecidable  in  general. 
However,  it  is  relatively  easy  to  apply  a  somewhat  weaker  test  as  follows: 

replace  each  application  of  a  computable  function  f  to  arguments  tl,  t2,  ...  by  a 
function  which  returns  the  term  f(tl,t2,...); 

for  each  application  of  a  computable  predicate  p  to  arguments  tl,  t2,  ...  ,  replace  it 
by  a  function  which  checks  if  p(tl,t2,...)  has  been  already  assigned  a  value,  and 
which  returns  the  same  value  if  so;  if  not,  it  first  returns  true  and  stores  the  value  for 
subsequent  checking;  on  backtracking,  it  then  returns  false,  also  storing  this  value. 

The  program  as  modified  systematically  follows  all  possible  paths,  so  if  it  terminates,  its 
domain  is  clearly  finite. 

The  last  procedure  could  be  used  in  theory  to  decompose  the  system  in  the  follow- 
ing way.  The  list  of  evaluatable  terms  and  predicates  replaced  should  be  saved;  these  can 
be  evaluated  prior  to  the  applications  of  any  rules.  The  values  of  the  predicates  are  then 
regarded  as  propositional  variables,  and  the  rules  are  replaced  with  the  appropriate 
instantiations,  which  thus  reduce  to  propositional  statements. 

3.1.  Representation  of  Clauses  over  Finite  Domains 

One  of  the  problems  with  this  approach  is  the  potential  number  of  instantiations  of 
clauses  which  may  be  necessary.  Essentially  one  proposition  is  required  for  every 
significant  state  which  can  occur.  Though  this  may  be  very  large,  the  amount  of  informa- 
tion per  proposition  is  small. 

One  representation  which  could  be  used  is  to  represent  a  clause  by  an  array  of  pro- 
positions, with  each  proposition  represented  by  a  link  to  its  next  occurrence,  and  a  link  to 
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all  propositions  which  could  be  used  to  solve  it.  This  is  in  general  a  graph  structure,  in 
which  each  occurrence  of  a  proposition  requires  two  pointers.  Systems  containing  mil- 
lions of  proposition  occurrences  could  be  handled  by  this  method. 

3.2.  Efficiency  of  Deductions  in  Finite  Domains 

We  can  get  some  feeling  for  the  efficiency  of  deductions  in  such  a  system  by  res- 
tricting consideration  to  Horn  clauses.  In  this  case  the  representation  graph  is  essentially 
a  directed  acyclic  graph  (dag). 

In  an  OPSx-style  implementation,  a  logical  inference  would  correspond  to  selection 
of  a  newly  inferred  proposition,  tracing  along  the  pointers  linking  it  to  clauses  it  can  help 
solve,  and  adding  to  the  conflict  set  those  clauses  which  were  solved.  The  time  to  do  this 
would  depend  on  the  number  of  such  clauses,  which  is  difficult  to  estimate.  However,  it 
seems  unlikely  that  this  would  generally  be  as  large  as  hundreds,  though  it  would  never 
be  zero  (otherwise  the  proposition  would  be  redundant).  For  an  average  of  ten  clauses 
per  proposition,  the  time  to  do  this  would  be  less  than  100  microseconds  per  step  on  a  1 
MIP  processor,  giving  more  than  10,000  LIPS. 

In  a  Prolog- style  implementation,  a  logical  inference  would  correspond  to  the  pro- 
pagation of  query  markers  from  a  goal  down  the  dag,  with  true  and  false  markers  being 
propagated  up  the  dag  when  relevant.  This  would  correspond  to  a  Prolog  implementation 
in  which  matching  a  literal  with  a  clause  head  was  reduced  to  propagating  a  marker  along 
a  pointer.  This  would  appear  to  give  gains  in  the  range  of  1(X)  to  10(X),  since  all  the  over- 
head of  creating  the  search  tree  and  matching  variables  is  eliminated. 

3.3.  Parallelism 

Initial  considerations  suggest  that  both  styles  of  implementation  would  lend  them- 
selves to  parallelization,  particularly  on  shared  memory  machines  such  as  the  NYU 
Ultracomputer  [Gottlieb83].  In  the  OPSx-style  implementation,  whenever  any  new  pro- 
position is  inferred,  propagation  of  its  effect  can  be  carried  out  in  parallel  with  that  of 
previously  inferred  literals.  The  amount  of  parallelism  would  depend  on  the  particular 
situation,  but  would  on  average  be  always  greater  than  two,  and  might  be  much  larger. 

In  the  Prolog-style  implementation,  all  alternatives  could  be  searched  in  parallel, 
without  the  problem  of  maintaining  independent  copies  of  variables.   Furthermore,  all 


conjunctive  goals  could  be  examined  in  parallel  also,  without  the  difficulty  of  interacting 
subgoals,  a  serious  problem  in  Prolog. 

Lastly,  we  note  that  this  model  lends  itself  to  implementation  on  network-like 
machines  such  as  that  proposed  in  [Fahlman79]  In  fact  our  model  is  simpler  than  many  of 
these  proposals,  since  there  are  only  two  kinds  of  links  and  a  small  number  of  markers. 

3.4.  Probabilities 

In  some  cases  it  may  be  appropriate  to  work  with  rules  which  have  probability 
measures  associated  with  them.  Traditionally,  there  have  been  two  difficulties  with  this: 
first,  there  is  no  satisfactory  probabilistic  theory  for  first-order  logic  [Ishizuka83];  and 
second,  the  notion  of  independent  evidence  cannot  be  captured  by  a  single  probability 
measure  for  each  rule. 

In  our  case,  we  cannot  easily  avoid  the  second  problem,  but  the  first  problem  disap- 
pears since  we  are  working  within  propositional  logic  for  which  there  is  a  sound  theory. 
Another  way  of  saying  this  is  that  we  can  supply  different  probability  measures  for  each 
of  the  instances  of  a  general  rule. 

4.  A  Methodology  for  Developing  Expert  Control  Systems 

We  suggest  here  that  conversion  of  a  rule-based  system  into  an  efficient  control  sys- 
tem can  be  done  by  the  analog  of  the  four  (human)  processes  described  above. 

Stepl 

Specialization  corresponds  to  replacing  general  parameters  by  their  actual  values, 
and  carrying  out  any  simplifications  which  result.  For  example,  general  knowledge  about 
sailboats  requires  the  ability  to  reason  about  the  effect  of  an  arbitrary  number  of  arbitrary 
sails,  using  a  mixture  of  empirical  knowledge,  simple  physics,  and  highly  complex  for- 
mulae; such  specifications  clearly  requires  variables.  In  a  specific  case  we  might  know, 
say,  that  there  are  only  2  sails,  and  they  are  of  types  A  and  B;  we  can  therefore  instantiate 
the  general  rules  to  these  two  sails,  eliminating  entirely  the  variables  representing  sail 
characteristics.  Furthermore,  we  might  be  able  to  simplify  the  set  of  rules  considerably 
by  methods  such  as  those  of  [Sickel77],  or  the  procedure  called  chunking  [Rosen- 
bloom82]  by  Rosenbloom  and  Newell. 
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Step2 

The  resulting  system  is  then  decomposed  into  two  components,  a  mode-recognizer 
of  the  form: 

mode  :=  compute_mode  (input_variables) 

where  compute_mode  is  expressed  in  rule-based  form,  and  the  number  of  modes  is  finite, 
and  a  mode-executer  of  the  form: 

output_variables  :=  compute_output  (mode,input_variables) 

where  compute_output  is  a  function  which  can  be  computed  rapidly.  In  general,  the 
decomposition  process  might  involve  extensive  transformation  of  the  program  to  force 
the  number  of  modes  to  be  finite,  and  so  might  be  highly  complex. 

Step  3 

The  compute_mode  system  is  then  further  transformed  to  make  its  effective  domain 
finite.  The  algorithm  described  above  can  be  used  to  check  this,  but  if  the  effective 
domain  is  not  finite  this  may  require  complex  transformations. 

Step  4 

If  step  3  is  not  successful,  or  if  the  resulting  system  is  finite  but  too  large,  the  rules 
specifying  the  function  compute_mode  can  be  supplemented  by  selective  instantiation  of 
the  rules.  The  resulting  system  would  then  consist  of  two  subsystems:  a  subsystem  G 
containing  the  rules  for  compute_mode,  which  would  operate  just  like  a  standard  rule- 
based  system;  and  a  subsystem  I  containing  the  instantiated  rules.  These  two  subsystems 
would  operate  in  parallel,  with  the  mode  being  determined  by  I  whenever  it  was  applica- 
ble, and  by  G  otherwise.  When  G  is  used  the  response  would  be  slower,  since  the  system 
would  be  'figuring  out  what  to  do'. 

We  discuss  decomposition  and  selective  instantiation  in  more  detail  below. 

4.1.  An  Example 

We  consider  the  following  example.  In  sailboat  racing,  one  of  the  standard  strategy 
principles  is  "Avoid  the  port-tack  layline"  (see,  for  example  [Walker66]).  If  expressed  in 
Prolog,  this  would  take  a  form  such  as: 
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want_to_tack  :- 

beating,  near_port_layline,  starboard_tack;. 

These  predicates  in  turn  would  be  defined  by  rules  such  as: 

beating  :- 

course_to_mark(C),  true_wind_direction(Twd), 

optimum_twa_beat(Otwa) , 

C  <  Twd+Otwa,  C  >  Twd-Otwa. 
near_port_layline  :- 

course_to_mark(C),  true_wind_direction(Twd), 

optimum_twa_beat(Otwa), 

C  >  Twd+Otwa-5. 
starboard_tack  :- 

apparent_wind_angle(Awa),  Awa  <  90. 
optimum_twa_beat(Otwa)  :- 

wind_speed(Ws),  otwa_from_ws(Ws,Otwa). 

with  the  unspecified  predicates  calculating  straight-forward  trigonometric  or  tabular 
functions  of  the  values  read  from  transducers.  This  set  of  rules  can  be  simplified  to: 

want_to_tack  :- 

course_to_mark(C),  true_wind_direction(Twd), 
optimum_twa_beat(Otwa),  Ptla  is  Twd+Otwa-C, 
Ptia  >  0,  Ptia  <  5, 
apparent_wind_angle(Awa),  Awa  <  90. 

4.2.  Decomposition 

As  suggested  above,  one  way  of  ensuring  a  finite  domain  recognition  component 
might  be  to  discretize  all  input  variables.  For  each  combination  of  values,  all  functions 
and  all  predicates  could  be  computed,  and  the  rules  replaced  with  their  appropriate 
instantiations.  In  general,  this  can  lead  to  a  combinatorial  explosion  in  the  number  of 
rules.  For  instance,  the  rule  in  the  example  described  above  would  have  to  be  replaced 
by  a  number  of  rules  of  the  form: 
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want_to_tack  :- 

course_to_mark_170,  true_wind_direction_l 30, 

optimum_twa_beat_42, 

apparent_wind_angle_30. 

In  practice,  courses  must  be  measured  to  at  least  5  degrees,  and  wind  angles  even  more 
accurately,  so  that  even  in  this  simple  example,  the  number  of  rules  would  be  enormous. 

To  be  specific,  we  suppose  that  the  input  variables  of  the  system  are  provided  by 
input  predicates,  such  as  wind_speed,  which  might  be  defined  as: 

wind_speed(X)  :- 

read_transducer(wind_speed,  X). 

Then  the  decomposition  procedure  described  above  will  identify  the  term  Twd+Otwa-C 
as  being  required,  so  this  can  be  computed  by: 

ptla(PUa)  :- 

twd(Twd),  otwa(Otwa),  course(C), 
,     Ptla  is  Twd+Otwa-C. 

and  the  rule  becomes: 

want_to_tack  :- 

ptla(Ptla),  Ptla  >  0,  Ptla  <  5, 
apparent_wind_angle(Awa),  Awa  <  90. 

Instantiation  would  then  replace  this  rule  by: 

want_to_tack  :- 

ptla_gt_0,  ptla_lt_5, 
awa_lt_90. 

(Note  for  sailors:  another  principle,  "Don't  overstand",  will  give  the  same  action  for 
values  of  Ptla  less  than  zero,  so  the  ptla_gt_0  can  be  eliminated). 


-11- 

4.3.  Selective  Instantiation 

The  basic  mechanism  that  we  propose  for  selecting  which  instantiations  to  use  is  the 
following  simple  learning  procedure. 

Start  with  the  set  G  of  general-purpose  rules  derived  above,  and  an  empty  I,  and 
present  G  with  a  sample  input  state  which  has  occurred  in  practice. 

Use  G  to  determine  the  correct  mode,  noting  which  functions  and  predicates  need  to 
be  computed,  but  ignoring  the  computations  which  do  not  contribute  to  the  answer. 

Add  code  to  I  to  compute  these  functions  fi  and  predicates  pi,  and  the  approriate 
instantiations  of  the  rules. 

Continue  this  process  for  as  many  input  states  as  is  possible,  each  time  adding  code 
to  compute  the  appropriate  functions  and  predicates. 

The  result  is  a  simple  program  consisting  of  a  set  of  assignments  which  can  all  be  exe- 
cuted in  parallel,  and  a  set  of  conditional  assignments  which  compute  one  value  for  the 
mode,  which  can  also  be  executed  in  parallel.  Optimization  of  this  program  can  be  done 
if  necessary,  using  common  subexpression  detection  and  boolean  simplification  tech- 
niques. 

Note  that  this  is  somewhat  different  from  the  procedure  called  chunking  [Rosen- 
bloom82]  by  Rosenbloom  and  Newell,  in  which  the  essential  improvement  is  derived  by 
collecting  together  general -purpose  subsets  of  rules.  It  is  also  different  from  that  sug- 
gested in  [Sickel77].  ,^ 

5.  Intelligent  Control  System  Languages 

If  step  3  is  successful,  and  the  system  is  a  finite  domain  program,  it  structure  is  very 
simple,  containing  just  assignments  and  conditional  assignments  inside  an  endless  loop. 
The  most  widely  studied  such  programs  are  found  in  spreadsheets,  which  thus  suggest 
themselves  as  possible  tools  for  development  of  expert  control  systems.  Furthermore,  the 
implementation  techniques  used  in  spreadsheets  of  keeping  track  of  dependencies 
between  variables  to  minimize  recomputations  when  values  are  changed  can  also  be  use- 
ful. This  also  suggests  alternative  strategies  for  different  recomputations;  for  example,  a 
lengthy  recomputation  which  is  anticipated  can  be  done  by  another  processor  in  parallel, 
while  the  original  processor  is  maintaining  the  more  frequent  updates. 
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